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Dynamic Link Exchange Protocol (DLEP) 

Control-Plane-Based Pause Extension 

Abstract 


This document defines an extension to the Dynamic Link Exchange 
Protocol (DLEP) that enables a modem to use DLEP messages to pause 
and resume data traffic coming from its peer router. 
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Introduction 


The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. 
It provides the exchange of link-related control information between 
a modem and a router. DLEP defines a base set of mechanisms as well 
as support for possible extensions. This document defines one such 
extension. 


The base DLEP specification does not include any data-plane 
flow-control capability. The extension defined in this document 
supports flow control of data traffic based on explicit messages sent 
via DLEP by a modem to indicate when a router should hold off sending 
traffic and when it should resume. This functionality parallels the 
flow-control mechanism found in PPP over Ethernet (PPPoE) per 
[RFC5578]. The extension also optionally supports DSCP-aware flow 
control ("DSCP" stands for "Differentiated Services Code Point") for 
use by Diffserv-aware modems. (For general background on 
Differentiated Services, see [RFC2475].) This functionality is very 
similar to that provided by Ethernet priority-based flow control; see 
[IEEE.802.10 2014]. The extension defined in this document is 
referred to as "Control-Plane-Based Pause". Other flow-control 
methods are possible with DLEP; for example, see [DLEP-DIFFSERV] and 
[DLEP-CREDIT]. 


Note that this mechanism only applies to traffic that is to be 
transmitted on the modem’s attached data channel and not to DLEP 
control messages themselves. Furthermore, it applies only to the 
single subnetwork that is used to connect a modem and a router, and 
for traffic sent from a router to a modem. 


This document defines a new DLEP Extension Type Value that is used to 
indicate the use of the extension; see Section 2. Three new DLEP 
Data Items are defined in Section 3. 


-l. Key Words 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Extension Usage and Identification 


The use of the Control-Plane-Based Pause Extension SHOULD be 
configurable. To indicate that the implementation supports the use 
of the Control-Plane-Based Pause Extension, an implementation MUST 
include the Control-Plane-Based Pause Extension Type Value in the 
Extensions Supported Data Item. The Extensions Supported Data Item 
is sent and processed according to [RFC8175]. 


The Control-Plane-Based Pause Extension Type Value is 2; see 
Section 5. 


Extension Data Items 


Three Data Items are defined by this extension. The Queue Parameters 
Data Item is used by a modem to provide information about the DSCPs 
it uses in forwarding. The Pause Data Item is used by a modem to 
indicate when a router should cease sending packets, and the Restart 
Data Item is used by a modem to indicate when a router can resume 
sending packets. 


3. 
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Queue Parameters 


The Queue Parameters Data Item is sent by a modem to a router to 
indicate DSCP values that may be independently paused. This Data 
Item MUST be included in a Session Initialization Response Message 
that also contains the Control-Plane-Based Pause Extension Type Value 
in the Extensions Supported Data Item. Updates to these parameters 
MAY be sent by a modem by including the Data Item in Session Update 
Messages. 


The Queue Parameters Data Item groups DSCPs into logical queues, each 
of which is identified by a "Queue Index" field. The number of 
logical queues is variable, as is the number of DSCPs associated with 
each queue. A queue size (in bytes) is provided for informational 
purposes. Queue Index fields are numbered sequentially from zero, 
where queue index zero is a special case covering DSCPs that are not 
otherwise associated with a Queue Index field. 


An implementation that does not support DSCPs would indicate one 
queue with zero DSCPs, and the number of bytes that may be in its 
associated link transmit queue. Additional logical queues are 
represented in a variable series of Queue Parameter Sub-Data Items. 


The format of the Queue Parameters Data Item is: 


0 1 2 3 
OV 2.34, 3.6.7 829: 0 L 23 4A 6 Tg 390 L 20 BA 6 7, 8:9: OT 
Pata Fata tata tata tata ta tata ta tata tata ta tata ta tata tatatatatatatatat 

| Data Item Type | Length 

Fatt ata tata tata tata ta tata ta tata tata tata tata tata tata tatatatatatat 
| Num Queues | Scale Reserved 
+-+-+-+-+-+-+-+-+-+-+ +H HH 
| Queue Parameter Sub-Data Item 1 

Fatt ata ta tata ta tata ta tata HHHMH 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Queue Parameter Sub-Data Item n 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Data Item Type: 
23 


Length: 
Variable 


Per [RFC8175], Length is the number of octets in the Data Item, 
excluding the Type and Length fields. 


Num Queues: 
An 8-bit unsigned integer indicating the number of Queue Parameter 
Sub-Data Items that follow. This field MUST contain a value of at 
least one (1). 


Scale: 
A 4-bit unsigned integer indicating the scale used in the Queue 
Size Qn field. The valid values are: 


+-----—- 4+-------------------------- + 
Value Scale 

+ + + 
0 B - Bytes (Octets) 

+------- 4+-------------------------- + 
1 KB - Kilobytes (1024 B) 

+------- 4+-------------------------- + 
2 MB - Megabytes (1024 KB) 

4+------- 4+-------------------------- + 
3 GB - Gigabytes (1024 MB) 


+------- 4+-------------------------- + 
Table 1: Queue Size Qn Field Values 


Reserved: A 20-bit field that MUST be set to zero (0) by the sender 
(a modem) and ignored by the receiver (a router). 


.1. Queue Parameter Sub-Data Item 


Queue Parameter Sub-Data Items are an unordered list composed of 
Sub-Data Items with a common format. The format of the Queue 
Parameter Sub-Data Item is patterned after the standard format for 
the DLEP Data Item; see [RFC8175], Section 11.3. Any errors or 
inconsistencies encountered in parsing Sub-Data Items are handled in 
the same fashion as any other Data Item parsing error encountered in 
DLEP. In particular, the receiving implementation MUST issue a 
Session Termination Message containing a Status Data Item with status 
code set to 130 ("Invalid Data") and transition to the Session 
Termination state. 


The format of the Queue Parameter Sub-Data Item is: 


0 1 2 3 
0.1 2-3 4.65: 6.7 8: 9 0 1-2. 3. :4.°5.-6 7 8. 9°.0° 1-2 3 4-56 7 8-9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++H+++++H 

| Sub-Data Item Type (1) | Length 

fof—f-4-4-4F-4-4F- 4-4-4 FF p papi pip pi pi pip pi pip papitata tit 
| Value... | 
fof-f-4-4F- 4-4-4 4-4-4 FFF ppp pi pip pi pip pi pip papitata t 


and Value has the format: 


0 1 2 3 

0 L 2 3 405 6.7 8 9 Ol 23: 4. 3-6. 7.890 123 4 5:6 Fh 8 9 O oT 
tata trtatrtatatartatatatatatotatatotaotatatatatatotatotatatatotatnt 
| Queue Index | Queue Size Qn 
E S A A E A A E A L A A O a a e a a A S E AL 
| Num DSCPs Qn | DS Field ọn | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+. 


-+-+-+-+-+-+-+-+ 
DS Field Qn | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 


Sub-Data Item Type: 
A 16-bit unsigned integer that indicates the type and 
corresponding format of the Sub-Data Item's Value field. Sub-Data 
Item Types are scoped within the Data Item in which they are 
carried, i.e., the Sub-Data Item Type field MUST be used together 
with the Queue Parameters Data Item Type to identify the format of 
the Sub-Data Item. This field MUST be set to one (1) for the 
Queue Parameter Sub-Data Item. 


Length: 
Variable 


Length is the number of octets in the Sub-Data Item, excluding the 
Type and Length fields. 


Queue Index: 

An 8-bit field indicating the queue index of the queue parameter 
represented in the Sub-Data Item. Only the first instance of a 
particular Queue Index value is meaningful. Subsequent Sub-Data 
Items containing the same Queue Index values, if present, MAY be 
logged via a management interface and MUST otherwise be ignored. 
Note that the value 255 is reserved and MUST NOT be used in this 
field. 


Queue Size Qn: 


3 


eae 


A 24-bit unsigned integer representing the size, in the octet 
scale indicated by the Scale field, of the queue that supports the 
traffic with the DSCPs associated with the queue index. 


Num DSCPs Qn: 
An 8-bit unsigned integer indicating the number of DSCPs 
associated with the queue index associated with the Sub-Data Item. 


DS Field Qn: 
The Data Item contains a sequence of 8-bit DS fields. The number 
of DS fields present MUST equal the Num DSCPs Qn field value. 


The DS field structure is the same as the structure shown in 
[RFC2474]. 


0 T 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
| DSCP |) eu | 
+---+---+---+---+---+---+---+---+ 


DSCP: Differentiated Services Code Point 
CU: Currently Unused; MUST be zero 
Pause 


The Pause Data Item is sent by a modem to a router to indicate to its 
peer that traffic is to be suppressed, i.e., paused. The motivating 
use case for this Data Item is when a modem’s internal queue length 
exceeds a particular threshold. Other use cases are possible, e.g., 
when there are non-queue-related congestion points within a modem. 
Such cases are not explicitly described in this document. 


A modem can indicate that traffic is to be suppressed on a 
device-wide or destination-specific basis. An example of when a 
modem might use device-wide suppression is when output queues are 
shared across all destinations. Destination-specific suppression 
might be used when per-destination queuing is used. To indicate that 
suppression applies to all destinations, a modem MUST send the Paus 
Data Item in a Session Update Message. To indicate that suppression 
applies to a particular destination, a modem MUST send the Pause Data 
Item in a Destination Update Message. 


Each Pause Data Item identifies the traffic to be suppressed by the 
Queue Index field (Section 3.1), which in turn indicates traffic 
identified by one or more DSCPs. The special value of 255 is used to 
indicate that all traffic is to be suppressed. 


While there is no restriction on the number of messages containing 
Pause Data Items that may be sent by a modem, a modem SHOULD include 
multiple queue indexes in the same message when possible. 


A router that receives the Pause Data Item MUST cease sending the 
identified traffic to the modem. This may of course translate into 
the router’s queues exceeding their own thresholds. If a received 
Pause Data Item contains a Queue Index value other than 255 or a 
queue index established by a Session Initialization or Session Update 
Message, the router MUST terminate the session with a Status Data 
Item indicating "Invalid Data". 


The format of the Pause Data Item is: 


0 1 2 3 
0123456789012345678°90123456789 01 
PoP H Fifi fifi tipi pipe pipe papi ipi pig p ipa g gti page git igigegot 

| Data Item Type | Length 
Poti Fifi foto f ipa pit pi pip t ipa pip g pip gti ti page git igpigegt 


| Queue Index 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Queue Index | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Data Item Type: 
24 


Length: 
Variable 


Per [RFC8175], Length is the number of octets in the Data Item, 
excluding the Type and Length fields. It will equal the number of 
Queue Index fields carried in the Data Item. 


Queue Index: 
One or more 8-bit fields used to indicate a queue index defined by 
a Queue Parameters Data Item. The special value of 255 indicates 
that (1) all traffic to the modem is to be suppressed when th 
Data Item is carried in a Session Update Message or (2) all 
traffic to a particular destination is to be suppressed when the 
Data Item is carried in a Destination Update Message. 


Restart 


The Restart Data Item is sent by a modem to a router to indicate to 
its peer that transmission of previously suppressed traffic may be 
resumed. An example of when a modem might send this Data Item is 
when an internal queue length drops below a particular threshold. 


The sending of this Data Item parallels the Pause Data Item (see 
Section 3.2) and follows the same rules. To indicate that 
transmission can resume to all destinations, a modem MUST send the 
Restart Data Item in a Session Update Message. To indicate that 
transmission can resume to a particular destination, a modem MUST 
send the Restart Data Item in a Destination Update Message. Finally, 
the same rules apply to queue indexes. 


A router that receives the Restart Data Item SHOULD resume 
transmission of the identified traffic to the modem. 


The format of the Restart Data Item matches the Pause Data Item 
and is: 


0 1. 2 3 
0123456789012345678901234567890 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Data Item Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Queue Index | : 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
a | Queue Index | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Data Item Type: 25 
Length: See Section 3.2. 
Queue Index: See Section 3.2. 

Security Considerations 
The extension defined in this document introduces a new mechanism for 
flow control between a router and modem using DLEP. The extension 
does not introduce any vulnerabilities that are inherently different 


from those documented in [RFC8175]. The approach taken to security 
in that document applies equally when running the extension defined 


in this document. 


Implementations of the extension defined in this document MUST 
support the configuration and use of TLS, as described in [RFC8175], 
in order to protect configurations where injection attacks are 
possible, i.e., when the link between a modem and router is not 
otherwise protected. 


Note that this extension does allow a compromised or impersonating 
modem to suppress transmission by the router or a switch that 


interconnects the modem and router. Similar attacks are generally 
possible with base DLEP -- for example, an impersonating modem may 
cause a session reset, or a compromised modem can simply drop all 

traffic destined for or sent by a router. [RFC8175] defines the us 


of TLS to protect against such impersonating attackers. 
IANA Considerations 


This document assigns four new values and creates a new subregistry 
in the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry. 


.1. Extension Type Value 


This document adds a new assignment to the DLEP extensions registry 
named "Extension Type Values" [RFC8175], per the "Specification 


Required" policy [RFC8126]. IANA has assigned the following value: 
+------ +--------------------------- + 
| Code | Description | 
+ + + 
| 2 | Control-Plane-Based Pause | 
+------ +--------------------------- + 


Table 2: Extension Type Value 


.2. Data Item Values 


This document adds three new assignments to the DLEP Data Item 
registry named "Data Item Type Values" [RFC8175], per the 
"Specification Required" policy [RFC8126]. IANA has assigned the 
following values: 


4+----------- 4+------------------ + 
Type Code Description 

+ + + 
23 Queue Parameters 

4+----------- 4+------------------ + 
24 Pause 

4+----------- 4+------------------ + 
25 Restart 

4+----------- 4+------------------ + 


Table 3: Data Item Values 


-3. Queue Parameter Sub-Data Item Values 


IANA has created a new DLEP registry named "Queue Parameter Sub-Data 
Item Type Values". 


Table 4 provides initial registry values and the registration 
policies [RFC8126] that apply: 


Type Code Description/Policy 

+ + + 
0 Reserved 

+------------- +------------------------ + 
Al Queue Parameter 

+------------- +------------------------ + 
2-65407 Specification Required 

+------------- +------------------------ + 
65408-65534 Private Use 

+------------- +------------------------ + 
65535 Reserved 

+------------- +------------------------ + 


Table 4: Initial Registry Values 
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